1. Field of Invention
The present invention relates to database systems. More specifically, the invention relates to the efficiently allocating memory in a document object model implementation for Java so that Java objects representing XML nodes may contain the same set of fields for both in-memory and database-backed representations.
2. Description of the Related Art
The use of Java platforms in conjunction with XML databases increasing and, as a result, many XML developer kits for Java are becoming readily available. A Java XML developer kit is generally a collection of tools that are used for XML data processing. Functionalities that are typically included in a Java XML developer kit include, but are not limited to, XML parsing, XSLT transformation, XML schema validation, and DTD validation, as will be appreciated by those skilled in the art. A Java XML developer kit also provides a document object model (DOM), as well as an application programming interface (API) for XML and a Java class binding API for manipulating XML data.
A Java XML developer kit generally represents XML data as tree structures of XML nodes. Typically, an XML node stores data such as a name of the node, the namespace associated with the node, text associated with the node, and attribute values associated with the node. An XML node also stores links to an owner document, a parent node, and any associated children or sibling nodes. While most implementations of an XML node generally maintain information such as the name of the node, the namespace associated with the node, text associated with the node, and attribute values associated with the node, as well as information pertaining to associated documents or nodes, the mechanism used to maintain such information generally depends upon factors which include, but are not limited to, the optimization of memory use.
When an object that represents an XML node is associated with an implementation that uses only local memory, e.g., when an object includes information that is all within the same Java space as the object, the object includes fields in which such information may be stored. Alternatively, when an object that represents an XML node is associated with an implementation that uses a database, e.g., when an object includes information that is stored in a database, the object uses a small number of fields to contain pointers to information stored in the database. Hence, an in-memory representation of an XML node, i.e., an object that uses only local memory, typically uses more memory resources than a database-backed representation of an XML node.
As previously mentioned, in a Java space environment, or a Java in-memory implementation of an XML node, an XML node is typically represented as a Java object with fields which contain the data and the links associated with the XML node. In many Java XML developer kits, while streaming input and output which may be used to read and to write XML data into or read XML data from a database are supported, the XML data processed and represented as in-memory Java objects in a Java space, and there is effectively no direct interaction with the database. FIG. 1a is a diagrammatic representation of a Java space environment with a Java object. A Java object 108 that contains XML data, i.e., represents an XML node, is present in a Java space 100. Java object 108 includes XML data and links 108 to associated elements such as child elements which may contain comments and attributes associated with Java object 108. Typically, XML data and links in Java object 108 are stored in multiple fields, i.e., fields in Java object 108 are used to store each piece of information associated with Java object 108.
While an in-memory Java object such as Java object 108 is highly functional, and may be efficiently processed using memory processing, such an object is not highly scaleable, as such an object is typically of a fixed size, and it may not always be possible to increase the size of the object enough to accommodate a desired amount of data. In order for objects which represent XML nodes to be scaleable, database-backed objects may be used to represent XML nodes. A database-backed object generally includes fields which hold pointers to data that is stored in a database. FIG. 1b is a diagrammatic representation of a Java space environment with a Java object which is substantially backed by a database. A Java object 114 is present in a Java space 110, and includes pointers 118 which point to data 124 that is stored in a database 122. Since data 124 is stored in database 122 rather than in fields within Java object 114, a significant amount of data 124 may effectively be associated with Java object 114. In other words, by storing data 124 within database 122, Java object 114 is scaleable in that the amount of data 124 associated with Java object 114 is not constrained by the size of Java object 114. Although a database-backed Java object such as Java object 114 is highly scaleable, database processing may be relatively slow compared to memory processing.
Depending on whether in-memory representations of XML data, i.e., in-memory Java objects, or database-backed representations of XML data, i.e., database-backed Java objects, are used, an appropriate DOM API set may be used by application developers. That is, specific sets of DOM APIs are used for different kinds of XML nodes. Hence, if an XML node is represented as an in-memory Java object, that XML node may not be used with a DOM API that are appropriate for database-backed representations of objects. Similarly, if an XML node is represented as a database-backed Java object, that XML node may not be used with a DOM API that is appropriate for in-memory representations of objects.
The inability for a single unified implementation to be used for in-memory representations of objects with database-backed representations of objects often limits developers, as many systems may not be compatible due to different representations of XML nodes. In order for a developer to enable a system which expects one type of object representation to accept a different type of object representation such that there is effectively interoperability relating to different object representations, significant changes to source code are often required, which is inefficient.
Therefore, what is needed is a method and an apparatus that allows a single DOM API set to be used to with both an in-memory representation of XML data and a database-backed representation of XML data. That is, what is desired is a system which effectively enables an object which represents an XML node to be compatible with both an in-memory representation of XML data and a database-backed representation of XML data.